Коллеги-сетевики, привет. К написанию данной статьи меня сподвигли задачи, с которыми приходилось сталкиваться во время работы с OSPF/IS-IS и тот набор решений, к которому я в конечном итоге пришел. Речь идет о насущном вопросе сетевых инженеров, когда приходится применять настройки на живой сети (пусть и с программируемым откатом на крайний случай) без возможности посмотреть как это отразится на всей сети в целом. Если отдельные команды и сценарии еще можно проверить в лабе, то получить полную реплику сети практически невозможно. В связи с этим я задался вопросом о наличии инструмента, который позволял бы строить слепок сети и рассчитывать её реакцию на ранее примененные настройки. Об этом сегодняшний туториал.

Теория. Задачи. Практика

Весь слепок сети (правильнее сказать слепок area) уже содержится компактно на каждом L3-устройстве в Link-State DataBase (LSDB) OSPF/IS-IS протокола. Достаточно лишь подключиться к одному устройству, сохранить её в текстовый файл и все связности в рамках одной области (area) у вас уже есть. Если областей несколько, то собрать LSDB с каждой из них. Далее достаточно правильно распарсить и построить математический граф с L3 устройствами в качестве нод (vertex) и OSPF/IS-IS соседством в качестве линков (edge) между ними. Имея такой граф, мы можем у себя на ПК делать с ним все, что захотим: удалять линки и изменять метрики на них, удалять сами ноды, строить маршруты и все это не затрагивая реальную сеть. К слову сказать на реальной сети можно и так посмотреть как будет проходить путь через tracert/traceroute/mtr, но не все устройства, в частности файерволы, покажут себя в этом выводе (пример №1). А также нет никакой возможности посмотреть какой будет резервный (backup) маршрут, если тот или иной участок из этого пути упадет. Именно это покажет нам граф-модель, в которой достаточно удалить edge и построить маршрут между теми же самыми устройствами заново. Тогда наикратчайший маршрут в измененной модели будет являться резервным маршрутом для нашего первоначального слепка сети (пример №2).

Представим, что сеть представляет собой совокупность разных по дизайну топологий: hub-and-spoke для подключения удаленных офисов и full или partial mesh между hub-ами. Каждый удаленный офис имеет основной (Primary) и запасной (Secondary,Backup) маршрутизатор и вы планируете перезагрузить secondary устройство. Повлияет ли это как-то на активный трафик? Если это резервный девайс, то через него не должно ничего проходить, но как это проверить? Оказывается достаточно просто — необходимо из каждой удаленной локации построить наикратчайший маршрут до нашей локации, где мы планируем провести работы, и тем самым убедиться используется ли secondary устройство для активного трафика или нет (пример №3). Дальше-больше, что, если мы действительно обнаружили такой трафик с таким flow, как нам это поменять? Тогда нам не обойтись без изменения метрик (cost) на сети.

Много достоинств у Link-State протоколов и мы уже оценили одно из них, когда одно устройство содержит в себе всю информацию по конкретной области, но есть и особенности, с которыми приходится считаться. В частности метрика назначается и принадлежит интерфейсу, а не префиксу, как это обстоит у BGP. Поэтому если мы изменили метрику на одном интерфейсе, то могли повлиять на traffic flow во всей area. Но рано или поздно менять метрики приходится и если на интерфейсе на данный момент выставлена метрика 10, то как это повлияет на распределение трафика, если выставить не 10, а 9 или 11? Вы уже наверное догадались, что и в этот раз мы можем себе позволить сделать это на графе и посмотреть реакцию сети на наши изменения (пример №4).

Сеть как живой организм — все в нем внутри тесно связан, взаимодействует между собой и состояние на «вчера» может отличаться от состояния текущего. Поэтому было бы неплохо также иметь возможность сравнивать состояние сети в разные отрезки времени. Имея копии LSDB, переведенные в граф, мы теперь уже можем сравнивать их и понимать: какие новые появились подсети, какие, наоборот, пропали, а также выявлять новые и старые L3-устройства (пример №5).

Прежде чем переходить к разбору примеров, хотелось бы остановиться на архитектуре найденного решения, на основе которого построена демонстрационная часть.

Архитектура. Безопасность

Решение представляет собой веб сервис, состоящий из Open-Source проектов:

• Nginx,

• MongoDB,

• Topolograph.

Благодаря контейнеризации, все составные части описаны в одном конфигурационном файле и запускаются одной docker compose up -d командой на Linux или Windows хосте. Такой подход имеет еще одно преимущество — безопасность, поскольку все загруженные данные о сети сохраняются в локальной MongoDB базе. Также данный сервис может быть помещен в DMZ зону, где разрешены только входящие HTTP запросы до Nginx, но запрещены все исходящие запросы за пределы зоны.

На рисунке изображена архитектура решения, которая запускается в среде Docker. При этом сервис может и не иметь доступа к сети, поскольку для построения графа необходим лишь текстовый файл с описанием OSPF/IS-IS LSDB.

Визуализация OSPF/IS-IS сети

Сбор LSDB с устройств различных вендоров

Для получения математической модели (графа) сети, необходимо сперва получить Link-State DataBase (LSDB) с реального устройства. Разные производители по-разному смотрят на формат вывода LSDB, но стоит отметить, что подавляющее большинство из них поддерживают RFC 2328.

Таблица с перечнем команд для сбора OSPF Link State DB. LSA1 и LSA2 являются обязательными для построения графа, в то время как LSA5 — опционален.

Таблица с перечнем команд для сбора IS-IS Link State DB.

Построенный граф на основе OSPF/IS-IS вывода LSDB

Чтение LSDB, её парсинг и построение графа считается успешным, если после загрузки файла с Link-State базой, отобразится топология сети. Граф динамический и интерактивный, то есть его можно перетянуть в нужное место на поле или выбрать ноду, до/с которой построить маршрут, нажав на нужную ноду правой кнопкой.

Жирной линией на графе отображены множественные (2 и более) связности между двумя нодами.

Построение кратчайшего пути. Пример №1

р№1″>

В самом начале статьи описывалась задача с построением актуальных путей между двумя устройствами. Результат расчета пути представлен на рисунке ниже. Дополнительно описывается маршрут с указанием каждого L3-устройства на сети (в трассировке используется OSPF RID (router ID)), а также метрика маршрута. 

На картинке выше изображены 4 наикратчайших маршрута (ECMP, Equal cost multipath) от L3 устройства с RID 123.14.14.14 до 123.123.30.30 с метрикой 41.

Представим также, что Вы знаете только IP адрес отправителя и IP адрес получателя. Для построения маршрута нужно знать на каком из L3-устройств затерминирована подсеть отправителя и получателя, и чтобы не тратить время на поиск, можно сразу начать вводить IP адреса в поле Focus/From и To. Терминирующие их устройства подставятся автоматически.

р№2″>

Нахождение резервного маршрута. Пример №2

Мы теперь знаем как выглядит наикратчайший маршрут, давайте посмотрим какой будет резервный путь, если устройство 123.10.10.10 потеряет связность с 123.30.30.30. Для этого достаточно лишь нажать на синий линк пути.

При потери связности между двумя устройствами, резервный путь будет состоять из четырех ECMP путей, иметь стоимость 50 и будет проходить через устройства 123.31.31.31 — 123.11.11.11.

Построение карты доступности устройства. Пример №3

Представим, что нода 123.30.30.30 основная, а 123.31.31.31 — резервная. Наша задача заключается в том, чтобы проверить доступность группы устройств слева от устройства 123.30.30.30 из любой точки нашей сети. Этого можно достичь при включенной опции «Print Minimum Shortest Tree (MST) for the node» и выбора меню «Build the shortest path to this node».

На рисунке выше изображены все наикратчайшие пути до ноды 123.123.30.30. Нода 123.30.30.30 действительно является основной для входящего трафика. 

Построение карты сетевой доступности до всех устройств сети

Продолжая пример с активным и резервным роутером выше, теперь давайте убедимся, что это справедливо и для исходящего трафика. Для этого построим наикратчайшие пути от устройства 123.123.30.30 до всех нод в сети при выборе «Build the shortest path from this node».

По полученной диаграмме выше можно заметить, что резервный маршрутизатор 123.31.31.31 также используется для исходящего трафика. Получается, что мы нашли асимметричный трафик на нашей сети.

Для того, чтобы находить участки с несимметричными путями, можно воспользоваться отчетом, который